1. Technical Field
The present disclosure relates generally to data buffers and, more particularly, to a method and apparatus for dynamic data buffers.
2. Description of the Related Art
Business objects are database entries (objects) containing one or more fields that are used to represent an entity of business practice. The types of business objects an enterprise stores in their database may depend on the business endeavour of the enterprise. For example, a business engaged in the purchasing and selling of goods may store business objects such as purchase orders, invoices, sales orders, etc. The amount of data being stored these days is immense. For example, business objects may have complex structures often with huge numbers of attributes and very often, huge number of records.
The time necessary to access a database is constantly decreasing. However, database access times are still often much longer than buffer memory access times. Accordingly, in order to minimize the number of database accesses required when an application such as a business application performs is a process requiring data from a database, an object can be retrieved from the database and stored locally in buffer memory. If the data is then needed again, it can be accessed from the buffer memory so that it is not necessary to again access the database for the data.
Each object contains attributes which are used for some particular business process. In present systems, when an object is requested and loaded into memory for performing some type of calculation, for example, the entire data set is loaded into a buffer. That is, fields used for performing the business process are loaded into buffer in addition to those fields not used in the business process. This leads to the use of unnecessarily large buffer memory.
Different approaches can be used to load objects. One approach is to store data in small application-specific tables as attribute sets. Although this approach may provide certain advantages, these are far outweighed by the disadvantages of the approach. For example, when the same attributes are used in different data sets, new data sets may need to be created or complex code changes may be required.
A second approach is to store all data in one large table. One of the biggest disadvantages of this approach is that to be implemented properly, requires a large amount of buffer memory.
FIG. 2 shows an example of the second approach. In the example shown in FIG. 2, in the database /APO/MATKEY, vertical columns represent fields in the database. Horizontal rows in the database represent a line of attributes. In this example, an application request is for “select MATID, MATNR, MEINS for MATID =“1”, “4”, “5”, “6””. In SCM Master Data Layer, for example, the system will select the data from the database and store the data in the buffer BUFFER table-wise using an instruction such as:
Select * FROM /apo/matkey INTO buffer WHERE matid IN (“1”, “4”, “5”, “6”)
Advantages of this approach are that there is no need for an artificial table split. In addition, it is able to serve all possible requests for attributes. However, disadvantages of this approach include the large use of memory for the buffer, more roundtrips per database select for data transport and unnecessary data (for this application) being read and stored.